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I. 


INTRODUCTION 


The  mission  of  naval  telecommunications  is  to  supply 
accurate,  secure,  reliable  and  rapid  communications  to  naval 
forces  and  commands  around  the  world.  The  Naval 
Telecommunications  system  (NTS)  also  has  responsibilities  as 
an  integral  part  of  the  Defense  Communications  System 
Automatic  Digital  Network  (AUTODIN) ,  which  provides  a 
connection  to  the  National  Command  Authority  and  the  other 
military  services. 

The  prime  element  in  judging  the  effectiveness  of  the 
NTS  is  the  determination  as  to  whether  the  system  can 
transfer  required  information  accurately  and  reliably  from 
originator  to  addressee  in  an  interval  timely  enough  to  be 
useful  to  the  recipient.  In  the  late  1960s,  serious 
questions  were  raised  concerning  the  ability  of  the  NTS  to 
meet  the  requirements  imposed  upon  it.  Delays  which  severly 
downgraded  service  below  acceptable  levels  were  occurring 
during  message  processing  at  originating  and  terminating 
communications  centers,  as  well  as  in  the  points  of 
interface  between  fleet  and  shore  systems.  In  order  to 
alleviate  the  delays  which  resulted  through  the  inefficient 
and  error  prone  procedures  involved  in  manual  processing  of 
messages,  emphasis  was  placed  on  developing  and  implementing 
automated  message  processing  systems  which  would  meet  all 
the  Navy’s  requirements  for  information  transfer.  This 
paper  will  examine  the  objectives  of  the  Naval 
Telecommunications  Automation  Program  (NTAP)  and  will 
describe  the-  innovations  in  automated  message  handling 
procedures  which  have  occurred  in  shore  communications. 
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Detailed  attention  will  be  focused  on  the  characteristics  of 
the  Naval  Communications  Processing  and  Pouting  System 
(NAVCOMPAES) . 
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II.  DISCUSSION  OF  NTAP 


Adoption  of  the  Naval  Telecommunications  Automation  Plan 
in  1971  established  guidelines  for  the  evolution  of  the  NTS 
into  an  automated  system  which  would  satisfy  the  demands 
placed  upon  communication  centers  ashore  and  afloat. 


A.  OBJECTIVES 


The  specific  objectives  of  the  NTAP  are  as  follows 
[Refs.  15  and  18]: 


a.  Improve  originator  to  addressee  delivery  times  to 
meet  designated  standards. 

b.  Obtain  a  timely  exchange  of  information  critical  to 
the  command  and  control  of  forces  afloat  through  the 
automation  of  message  processing  functions. 

c.  Provide  a  capability  to  effect  consolidation  of 
telecommunication  facilities  and  functions  to  allow 
significant  manpower  and  equipment  savings. 

d.  Eliminate  current  slow  manual  operations  to  reduce 
error  rates  and  to  allow  more  efficient  utilization  of 
personnel. 

e.  Make  maximum  use  of  high  speed  data  links 
(satellites)  and  provide  more  efficient  operation 
during  crises  situations. 


B.  PLANNING  PRINCIPLES 


Several  principles  were  delineated  tc  govern  the 
implementation  of  the  NTAP.  Due  to  the  urgent  nature  of  the 
requirements  for  automated  processing  systems  and  the 
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availability  of  commercial  hardware,  maximum  use  would  be 
made  of  off-the-shelf  hardware  in  order  to  decrease 
developmental  cost  and  to  permit  the  most  cost-effective 
installation  of  the  system.  Hardware  and  software  would  be 
modular  in  design  in  order  to  ensure  flexibility  in  the 
system,  and  procurement  practices  would  be  oriented  toward 
maintaining  compatibility  between  subsystems.  Consideration 
was  to  be  given  to  utilizing,  where  possible,  relatively 
simple  input-output  terminals  which  would  operate  under  the 
control  of  a  more  sophisticated  host  processor. 
Additionally,  systems  would  be  *user  transparent'  to  provide 
maximum  usability  with  minimum  training.  Due  to  space 
limitations  prevalent  on  a  large  number  of  ships,  the  NTAP 
stressed  the  requirement  that  the  maximum  number  of 
communications  functions  would  be  performed  ashore,  thereby 
minimizing  the  equipment  inventories  needed  on  board  ship?. 


C.  COHPCNENIS  OF  THE  SHORE  ESTABLISHMENT 


The  NTAP  encompasses  automation  projects  in  shore 
communications,  fleet  communications  and  the  interface 
between  the  two,  which  is  basically  the  Fleet  Satellite 
Communications  (FLTSATCOM)  Program.  Present  planning  calls 
for  a  shore  subsystem  to  be  composed  of  seventeen  Local 
Digital  Message  Exchanges  (LDMX)  for  major  telecommunication 
centers,  five  NAVCOMPARS  for  Naval  Communication  Stations 
(NAVCOMMSTA) ,  and  ninety-five  Remote  Information  Exchange 
Terminals  (RIXT)  for  small  telecommunications  centers  in  the 
immediate  area  of  an  LDMX/NAVCOMPARS.  Each  of  these  systems 
is  designed  to  eliminate  to  the  greatest  extent  possible 
manual  intervention  in  the  processing  of  messages.  RIXT  is 
being  devised  to  utilize  an  LDMX/NAVCOMPARS  computer  as  a 
host  for  processing  functions  including  message  entry, 
logging,  routing,  formatting,  file  and  retrieval.  RIXT 
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installations  at  telecommunication  centers  will  generally 
replace  presently  existing  Autodin  terminals.  In  order  to 
comply  with  the  planning  principles  of  the  NTAF,  NAVCCMPAH3 
software  will  be  used  on  future  LDHX  systems,  and  presently 
operating  LDhX  sites  will  be  transitioned  to  it.  The  LDMX 
at  San  Diego  is  currently  operating  with  modified  NAVCOMFAES 
software. 
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III.  MIcokp&rs  system  description 


A  r€al-time  system  devoted  exclusively  to  naval 
telecommunication  applications,  NAVCOHPABS  is  a  tactical 
system  designed  primarily  to  provide  an  automated  fleet 
broadcast  and  an  automated  entry  into  Autodin.  When 
PLTSATCOM  is  completely  operational,  NAVCOMPARS,  in 
conjunction  with  Autodin,  will  enable  ships  to  have  the 
capability  for  high  speed  point-to-point  transmissions. 
NAVCOMPARS  also  provides  administrative  and  service 
functions  to  over-the-counter  (OTC)  users. 


A.  EQUIPMENT 


Due  to  tie  critical  nature  of  its  command  and  control 
function  as  a  link  to  the  operating  forces,  NAVCCMPARS 
requires  an  extraordinary  degree  of  system  reliability.  To 
provide  for  this  key  factor,  NAVCOMPARS  consists  of  a 
duplexed  Dnivac  series  70/45  system.  Under  this  duplexed 
configuration,  one  central  processing  unit  and  associated 
equipment  are  on-line,  while  the  second  CPU  is  maintained  in 
the  back-up  mode.  A  multiplexor  is  an  integral  part  of  the 
CPU  and  is  capable  of  accomodating  256  devices  in  a  wide 
variety  of  configurations.  Each  CPU  has  communications 
capabilities  when  equipped  with  appropriate  communications 
equipment.  The  communications  module  is  composed  of  two 
multi-channel  communications  controllers,  up  to  82  teletype 
devices,  two  Dataspeed  readers,  an  Optical  Character  Reader 
(OCR)  and  10  Video  Data  Terminals  (VDT)  .  The  Multi-channel 
Communications  Controller  (CCH)  is  a  communications 
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coordination  device  which  provides  a  capability  to 
accomodate  up  to  48  half-duplex  channels  and  provides  the 
computer  systems  interface  for  the  VDTs,  dedicated  channels, 
teletypewriter  logs,  medium  speed  readers,  OCR,  satellite 
and  broadcast  channels.  [Refs.  15  and  16]  A  memory 
protection  feature,  which  allows  up  to  sixteen  levels  of 
memory  separation,  maintains  memory  and  program  integrity  in 
a  multi-programming  environment.  The  internal  logic  for 
elementary  operations  is  contained  in  read-only  memory. 

Software  has  been  developed  by  Naval  Command  Systems 
support  Activity  to  accomodate  the  requirements  of  various 
actual  and  proposed  locations;  therefore,  identical  software 
has  been  installed  at  all  operating  sites.  Standardization 
of  software  has  been  rigidly  maintained,  and  system 
modifications  are  implemented  only  as  directed  by  program 
changes  from  NAVCOSSACT.  Flexibility  has  been  built  into 
the  system  through  incorporation  of  a  modular  design,  which 
for  example  will  accept  the  program  additions  necessary  for 
satellite  communications.  Each  subsystem  must  fit  properly 
within  the  total  system,  but  the  various  subsystems  were 
initially  developed  as  separate  sections  of  software.  A 
dual  file  concept  is  utilized  to  provide  a  fall  back 
capability.  This  is  significant  because  it  allows  the 
back-up  set  cf  routing  files  to  be  used  for  the  daily  update 
action  while  the  on-line  system  is  operating. 


B.  MESSAGE  FLOW  ANALYSIS 


NAVCOMPAES  automates  message  processing  activities  in 
three  areas  of  a  NAVCOMMSTA:  Fleet  Center,  Computer  Center 
and  Message/Service  Center.  In  addition  to  the  major 
function  of  automatically  keying  on-line  the  fleet 
broadcast,  procedures  managed  by  NAVCOMPARS  include 
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preparation,  routing,  formatting,  code  conversion, 
validation,  editing,  transmission,  filing,  recalling, 
re-addressal  and  retransmission.  The  system  also 
distributes  OTC  traffic,  handles  data  traffic,  generates 
statistics  and  maintains  a  real-time  fleet  locator.  Using 
Figure  1  as  a  reference  source,  this  paper  will  detail  the 
procedures  involved  in  processing  narrative  traffic  through 
the  subsystems  of  a  NAVCOMPARS. 

1 .  Message  Entry 


Messages  are  entered  in  NAVCOMPAHS  through  Autodin 
Switching  Centers  (ASC) ,  over-the-counter  procedures 
(primarily  OCR  for  narrative  traffic) ,  on-line 
dedicated/full  period  channels  and  off-line  full  period 
channels. 


a.  Autodin 


Autodin  messages  in  JANAP  128  format  are 
received  via  the  Autodin  Interface  Subsystem  (AIS)  which  is 
resident  in  two  Onivac  70/1600  Autodin  Communication 
Controllers.  This  digital  stored  program  processor,  which 
supplies  the  connection  between  the  ASC  and  NAVCCMPARS 
maintains  synchronization  with  the  ASC,  strips  control 
characters  from  incoming  line  blocks  and  checks 
block/character  parity.  Under  the  dual  homing  concept, 
simultaneous  interfaces  will  be  maintained  with  two 
different  ASCs. 

The  message  then  is  received  by  the  Autodin 
Control  Subsystem  (ACS)  ,  which  is  resident  in  the  70/45 
processor.  ACS  accepts  message  input  from  AIS  and  then 
utilizes  the  Communications  Control  Subsystem  (CCS)  to 
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Figure  I  -  FLOW  OF  MESSAGE  INFORMATION  (Rel.  15,  p.  Bl) 


notify  the  Receive  Control  Subsystem  (RCS)  of  receipt  of 
data.  ACS  acknowledges  to  AIS  for  each  line  block  received; 
additionally,  when  an  entire  message  is  processed  and 
accounted  for  by  RCS,  ACS  will  send  an  end  of  message  (ROM) 
acknowledgement  to  the  Autodin  Controller. 

The  RCS  is  an  interrupt  driven  subsystem  capable 
of  interfacing  with  all  sources  of  input  concurrently.  It 
is  responsible  for  channel  coordination  to  ensure  that  all 
traffic  received  is  correctly  identified  and  that  any  errors 
in  sequence  cf  messages  or  SOH-EOM  will  be  detected.  After 
translating  Autodin  messages  from  ASCII  to  EBCDIC,  RCS 
assigns  each  message  a  processing  precedence  and  then. queues 
the  message  fcr  the  Message  Processing  Subsystem  (MPS) .  RCS 
records  each  message  received  on  two  separate  on-line  disk 
files  for  recovery  purposes  in  case  of  system  failure. 


b.  Cn-line 


Messages  are  entered  into  NAVCOMPARS  on-line  via 
OCR,  on-line  dedicated  channels  and  full  period 
terminations.  On-line  dedicated/full  period  channels  can  be 
landline  channels  to  ships  in  port,  electronic  courier 
circuits  to  on-base  users  or  landline  quality  full  period 
terminations  to  ships  at  sea.  Satellite  channels  are 
expected  to  be  of  landline  quality  and  will  be  on-line 
directly  into  NAVCOMPARS  for  both  incoming  and  outgoing 
traffic. 


Ihe  entry  point  for  on-line  traffic  is  via  the 
CCS,  which  queues  communications  device  interrupts, 
distributes  these  interrupts  to  the  appropriate  subsystem 
and  checks  for  errors  on  communication  devices.  This 
subsystem  supervises  the  logs  generated  by  the  teleprinter 
(channel  log,  service  log,  outgoing  log  and  temporary 
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Autodin  log)  and  interfaces  with  the  OCR,  Dataspeed  reader, 
VDT  and  on-line  teletype.  OCR  messages  are  converted  by  RCS 
to  modified  ACP  126  format.  The  ASCII  code  used  by  the  OCR 
is  translated  into  EBCDIC.  RCS  then  performs  input 
processing  corresponding  to  that  performed  on  Autodin 
traffic  on  all  the  above  categories  of  messages. 


c.  Off-line 

Off-line  channels  are  high  frequency  radio 
channels  which  are  not  of  suitable  quality  for  direct 
interface  into  the  system.  Torn  tape  procedures  are 
utilized  for  the  interface  with  NAVCOMPAES.  Upon  receipt, 
each  message  is  visually  screened.  If  the  message  is 
acceptable,  it  is  entered  into  the  system  via  medium  speed 
paper  tape  readers  which  interface  with  CCS.  Messages  are 
then  passed  to  RCS  for  input  processing  and  conversion  of 
five  level  baudot  code  to  EBCDIC.  All  narrative  messages 
will  be  converted  to  one  of  two  basic  formats,  JANAP  128  or 
modified  ACP  126.  Use  of  basic  formats  and  a  common  data 
code,  EBCDIC,  allows  for  minimization  of  the  number  of 
message  analysis  routines  needed  in  processing. 

2 •  Message  Processing 


Control  of  messages  passes  from  RCS  to  the  Message 
Processing  Subsystem  (MPS) .  NAVCOMPARS  processes  three 
forms  of  traffic;  narrative,  data  pattern  and  readdressals. 
Eeaddressals  are  previously  transmitted  messages  which  are 
designated  for  transmission  by  one  of  the  original 
recipients  to  a  command  not  on  the  initial  distribution. 
These  messages  require  the  generation  of  a  new  message 
header  upon  subsequent  transmission.  MPS  is  responsible  for 
message  analysis  and  functions  such  as  format  conversion 
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from  modified  ACP  126  to  JANAP  128,  header  validation, 
routing  indicator  assignment,  susdupe  processing  to 
eliminate  duplicate  messages,  broadcast  guard  list 
processing,  generation  of  broadcast  recap  messages  and 
determination  of  OTC  and  broadcast  delivery  requirements. 
Messages  can  be  recalled  on-line  for  up  to  ten  days  and  MPS 
will  build  and  append  headers  for  readdressal.  The  only 
processing  dene  to  the  text  of  the  message,  other  than 
classification  and  special  handling  checks,  is  the  insertion 
of  the  proper  paging  and  sectioning  information.  MPS  will 
display  error  conditions  or  specifically  requested 
information  to  the  VDT  operator  in  order  to  perform 
functions  involved  with  message  recalls,  routing  and 
distribution,  file  displays,  channel  status  and  control, 
message  entry,  broadcast  screens  and  message  editing. 
Changes  in  rcuting  files  can  be  entered  on-line  by  the  VDT 
operator  in  order  to  effect  immediate  shift  in  guard  list 
responsibilities.  NAVC0MPA3S  possesses  traffic  management 
features  which  permit  the  operators  to  closely  monitor 
traffic  queues  and  to  establish  alternative  transmission 
paths  to  eliminate  backlog  conditions.  Using  a  VDT, 
supervisory  personnel  can  visually  inspect  the  queues 
existing  on  a  specific  channel  and  can  activate  rerouting 
procedures  via  VDT  entered  command.  Separate  queue  reports 
can  be  displayed  to  show  queue  status  for  the  total  system 
with  a  breakdown  by  processing  step  and  precedence  as  well 
as  the  number  of  messages  by  precedence  being  queued  for 
each  outgoing  channel. 

The  Transmission  Processing  Subsystem  (TPS)  receives 
message  information  from  MPS,  utilizing  the  delivery 
instructions  generated  by  MPS  to  determine  the  destination 
queues  to  which  the  message  will  be  linked.  Prior  to 
assigning  a  message  to  a  transmission  channel  queue,  TPS 
ensures  that  the  security  classification  of  the  channel 
matches  that  of  the  message.  If  a  security  mismatch  exists. 
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the  message  is  automatically  delivered  to  either  the  Service 
Center  or  Top  Secret  Control  for  alternate  routing 
determination  or  off-line  encryption.  TPS  coordinates  the 
creation  of  journal  entries  after  all  destinations  have 
received  the  message. 


3 •  Message  Delivery 


Responsibility  for  the  delivery  of  messages  to  a 
communications  channel  or  terminal  device  is  lodged  in  the 
Transmission  Control  Subsystem  (TCS) .  This  subsystem 
interfaces  with  the  Service  Center  line  printer.  Message 
Center  mat  printer,  paper  tape  punch,  card  punch.  Top  Secret 
courier,  electronic  courier  circuits,  broadcast  channels, 
full  period  channels,  dedicated  channels  and  Autodin.  TCS 
provides  for  format  and  code  conversion  for  the  outgoing 
line,  editing,  routing  line  segregation  and  broadcast 
reruns.  NA7C0MPARS  processes  messages  by  precedence  on  a 
first-in  first-out  basis.  Provisions  have  been  established 
for  interruption  by  Emergency  Command  and  FLASH  messages. 
These  messages  will  be  retransmitted  immediately  after  their 
original  transmission  and  again  fifteen  minutes  later.  The 
message  interrupted  for  higher  precedence  traffic  is 
repositioned  at  the  head  of  its  respective  gueue  and  is 
retransmitted  under  a  new  number. 


a.  Autodin/OTC 

Dnder  the  dual  homing  concept  of  operations, 
simultaneous  interfaces  are  maintained  with  two  separate 
Autodin  Switching  Centers,  and  messages  are  automatically 
assigned  to  the  appropriate  channel.  TCS  interfaces  with 
the  Autodin  Communications  Controller  through  AIS.  ACS 
generates  Autodin  log  entries  upon  receiving  acknowledgement 
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from  the  hSC  for  SOM,  EOa  or  cancellation.  The  NAVCOMMSTA 
Message  Center  retains  responsibility  for  reproduction  and 
distribution  of  traffic  to  OTC  users.  NAVCOMPARS  can 
automatically  distribute  a  specified  number  of  copies  to 
applicable  commands  according  to  several  arguments  including 
standard  subject  identification  code  (SSIC)  and  flagwords, 
or  it  can  perform  internal  command  distribution  by  office 
codes  for  designated  users.  When  a  message  is  printed  at 
the  mat  printer,  the  system  displays  delivery  lines,  copy 
counts  and  internal  distribution  at  the  bottom  of  the  first 
page  of  the  message.  At  this  point,  the  message  is  at  the 
end  of  the  automated  process  and  probably  has  not  been  seen 
by  anyone  at  the  receiving  communications  center.  One  of 
the  new  billet  descriptions  for  NAVCOMPARS  calls  for  an 
editor  who  will  examine  each  message  prior  to  reproduction 
in  order  to  detect  errors,  such  as  garbles  within  the  text, 
which  would  not  have  been  identified  by  software  processing. 


b.  Fleet  Broadcast 

NAVCOMPARS  has  the  capability  to  automatically 
key  up  to  seventeen  channels  of  the  fleet  broadcast  with 
both  single  and  multi-channel  circuits  being  keyed.  Traffic 
on  the  broadcast  will  be  in  modified  ACP  126  format; 
messages  will  be  edited  to  delete  format  lines  1,  2,  3,  4, 
15,  and  all  paging  information.  (See  Figure  5  for  an 
explanation  cf  modified  ACP  126  format.)  The  system  is 
structured  so  an  operator  can  exercise  control  over  the 
broadcast  by  VDT  command  to  either  hold  traffic  due  to  an 
outage  or  to  initiate  altroute  procedures  to  relieve 
overloaded  queues.  A  delayed  rerun  channel  will  normally  be 
assigned  for  each  first  run  traffic  channel  of  a 
multi-channel  broadcast  with  activation  being  accomplished 
by  VDT  command.  An  additional  feature  provides  for 
automatic  message  rerun  when  no  queue  of  first  run  traffic 
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exists. 


c.  Cn-line/Off-liQe  Channels 


Ail  outgoing  messages  sent  to  channels  of 
dedicated  landline  quality  will  be  transmitted  on-line  by 
the  system.  Messages  addressed  to  ships  terminated  off-line 
will  be  delivered  to  a  low  speed  paper  tape  punch  associated 
with  each  full  period  termination.  An  operator  will 
manually  perform  the  send  operation,  repeating  transmission 
until  the  addressee  acknowledges  receipt  of  a  legible  copy. 
Prescribed  format  for  both  on-line  and  off-line  channels  is 
JANAP  128  with  non- pertinent  routing  indicators  being 
automatically  deleted. 


4.  Reports  and  Statistics 


The  various  subsystems  within  the  central  processor 
are  all  under  the  control  of  the  Executive  Control  Subsystem 
(ECS) .  The  ECS  monitors  the  multi-programming  environment 
and  controls  the  exchange  of  information  between  subsystems 
and  user  programs.  ECS  includes  functional  areas  involved 
with  console  control  whereby  the  programming  is  affected  by 
the  computer  operator;  iaput/output  control  which  allocates 
peripheral  devices  to  programming  modules  and  subsystems; 
program  control  which  allocates  the  CPU  to  various 
subsystems  on  a  priority  basis;  and  interrupt  control.  The 
CPU  is  allocated  in  the  following  descending  order: 
executive,  highest  communications  I/O  functions, 
communications  processing  functions  and  support.  The 
Support  Program  Subsystem  (SPS)  supervises  report  generation 
and  file  maintenance.  The  dual  nature  of  the  files  allows 
updating  to  be  accomplished  off-line.  Statistical  analysis 
reports  are  generated  daily  summarizing  key  message 
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processing  and  traffic  statistics 


Message  files  are  maintained,  both  on-line  and 
off-line.  A  six  months  file  of  messages  for  retrieval 
purposes  is  stored  on  magnetic  tape,  while  separate  on-line 
files  are  designed  to  be  kept  for  either  ten  or  thirty  days. 
The  ten  day  file  is  o^a  direct  access  storage  and  is  utilized 
for  broadcast  channel  reruns,  broadcast  screen,  susdupe  and 
service  actions.  The  thirty  day  file  is  to  support  on-base 
users  for  readdressal,  reference  routing  and  redistribution 
reguirements. 


C.  MANPOWEB  BEQUIREMENTS 

In  accordance  with  the  iJTAP  goal  to  reduce  manpower 
levels,  automated  systems  are  to  perform  the  routine  message 
handling  chores,  thereby  releasing  personnel  for  more 
creative  tasks  in  management  and  supervisory  areas.  Actual 
manpower  reductions  are  expected  to  vary  from  station  to 
station  depending  on  the  degree  of  automation  and  the  volume 
and  type  of  traffic.  The  design  intent  was  to  create  a 
“user  transparent”  system.  For  some  operating  positions 
this  has  been  accomplished,  and  personnel  familiar  with 
manual  techniques  can  transition  over  to  working  competently 
with  the  automated  system  after  a  month  or  less  of 
on-the-job  training.  Other  positions  require  new  skills, 
and  personel  assigned  these  jobs  routinely  need 
approximately  three  months  of  intensive  on-the-job  training 
to  acquire  proficiency.  Consequently,  personnel  familiar 
with  manual  techniques  can  be  expected  to  transition  over  to 
operation  of  the  automated  system  with  minimal  training. 


1 . 


NAVCCMPARS  Billets 


A  NAVCOMPARS  requires  the  creation  of  58  billets 
which  are  unique  to  the  operation  of  this  automated  system. 
Of  these  new  billets,  56  are  identified  for  the  Radioman 
(EM)  rating  and  two  are  for  Data  Processing  Technicians 
(DP) .  Experience  at  operational  installations  has 
demonstrated  that  the  average  radioman  can  handle  computer 
operations;  therefore,  RMs  are  being  assigned  to  positions 
such  as  computer  operator,  router,  OCR  operator  and  Fleet 
Center  command  7DT  operator.  The  billet  for  the 
Programmer/Systems  Analyst  is  for  a  Chief  Data  Processing 
Technician,  while  a  First  Class  Data  Processing  Technician 
fills  the  Assistant  Programmer  billet.  As  part  of  their 
duties,  the  DPs  will  assist  in  the  installation  of 
succeeding  versions  of  the  system  and  will  update  the 
current  system  in  accordance  with  program  changes  from 
NAVCOSSACT.  Additionally,  they  are  responsible  for  on-site 
software  maintenance  and  problem  documentation.  A  new  Navy 
Enlisted  Classification  Code  (NEC) ,  DP-2746,  has  been 
established  for  LDHX/NA VCOMPAES '  programmer/system  analysts. 
Source  ratings  are  D?  and  RM.  The  above  billet  requirements 
concern  cnly  those  positions  necessary  for  the  NAYCCNPARS 
installation;  many  existing  billets  required  for  a  manual 
system  will  be  transferred  unchanged  to  an  automated  one. 
Personnel  will  still  be  needed  to  fill  administrative  and 
supervisory  positions  such  as  communications  watch  officers 
and  section  supervisors.  Since  message  reproduction  and 
distribution  has  not  been  automated,  these  functions  must 
still  be  performed  manually.  Despite  the  creation  of  new 
billets,  substantial  personnel  savings  can  be  realized  with 
an  automated  system.  Major  reductions  for  a  NAVCOMMSTA  will 
occur  in  the  Fleet  Center  and  the  Message  Center.  The 
largest  saving  in  the  Fleet  Center  is  a  result  of  NAVCCMPARS 
keying  the  fleet  broadcast  on-line.  Eliminated  are  such 
jobs  as  broadcast  operator,  recap  operator  and  broadcast 
traffic  checker.  Reductions  have  been  made  also  in  the 
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nuaber  of  parsonnel  raquired  as  torn  tape  operators  for  the 
broadcast  and  full  period  terminations.  Cuts  in  the  Message 
Center  have  occurred  through  the  elimination  of  manual 
look-up  of  routing  indicators,  assignment  of  OTC 
distribution  and  tape  cutting  operations. 

2.  Statistics  from  NAYCOMMSTA  Norfolk 


A  study  of  personnel  requirements  of  NAVCCHMSTA 
Norfolk  before  and  after  installation  of  a  NAVCOHPAHS 
highlights  the  areas  where  personnel  reductions  are  most 
prominent.  The  following  summary,  taken  from  Reference  28, 
emphasizes  the  impact  that  automation  has  had  on  the  Fleet 
Center  and  Message  Center. 


BE  FORE 


NAJ^p^STA  NORVA 

NAYCOHPASS 

HAYCOMPARS 

INCH/DECR 

Management  Group 

007 

009 

-02 

Watch  Officers 

008 

008 

Fleet  Center 

041 

097 

-56 

Computer  Center 

019 

024 

-05 

Message  Center 

050 

089 

-39 

Service  Center 

012 

012 

Bata  Base  Maintenanc 

e  013 

000 

+  13 

TOTAL 

150 

239 

-89 

These  above 

NAYCOMMSTA  Norfolk 

reductions 

had  been 

were  realized  even  though 
automated  previously  to  a 

limited  degree.  NAVCOMPARS  replaced  an  Autodin  IBM  360/20 
installation.  As  noted  above,  the  total  number  of  personnel 
needed  for  operation  of  the  computer  center  decreased 
because  the  IBM  360/20  required  extra  operators  to  handle 
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manual  message  entry  and  removal  from  terminal  equipment. 
The  NAVCOMPAES  computer  center  is  not  involved  in  message 
input/output  procedures.  Since  the  present  NAVCOMPAES 
installations  are  on  maintenance  contracts,  requirements  for 
Navy  maintenance  personnel  are  also  reduced;  however,  the 
cost  of  maintenance  contracts  would  negate  any  actual 
monetary  savings.  The  above  figures  are  representative  only 
of  NAVCCMMSTA  Norfolk  and  can  not  be  projected 
unconditionally  to  the  other  NAVCOMPAES  sites,  but  the 
poten-tial  for  personnel  reduction  and  improved  message 
processing  through  automation  clearly  exists.  The 
realization  of  these  personnel  reductions  requires  the  full 
support  of  the  cognizant  command.  All  too  often,  a  command 
will  not  give  up  billets  whose  functions  have  been 
eliminated  due  to  automation.  Stations  have  used  these 
released  manpower  assets  to  augment  shortages  perceived  in 
other  areas;  thus  the  only  effect  of  communications 
automation  has  been  the  shift  of  personnel  resources  within 
a  command,  with  no  total  manpower  reduction  resulting. 


3 .  Training 


One  design  objective  of  the  LDMX/N^VCOMPAES  system 
was  that  additional  schooling  should  not  be  required  prior 
to  assignment  of  personnel  to  NAVCOMPAES  sites. 
Consequently,  the  formal  training  program  for  NAVCOMPAES 
operating  personnel  is  rather  limited.  No  training  course 
is  taught  at  any  military  school,  and  the  major 
responsibility  for  training  has  been  inherited  by 
NAVCOSSACT.  NAVCOSSACT,  assisted  by  Onivac  instructors, 
conducts  four  weeks  of  training  for  computer 
programaers/system  analysts.  On  site  training,  also 
conducted  by  NAVCOSSACT  and  consisting  of  classroom 
presentations  and  on-the-job  training,  is  concentrated  in 
the  seven  weeks  prior  to  test  and  acceptance  of  a  system  at 
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each  individual  location.  This  is  a  one-time  effort,  and 
the  indoctrination  of  subsequent  replacements  has  been  been 
left  to  the  individual  command,  although  NAVCOMMSTA  Norfolk 
is  currently  preparing  video-tapes  and  programmed  lessons 
for  use  as  instructional  material  by  all  NAVCOMPASS  sites. 
Experience  at  Norfolk  has  demonstated  that  individuals  can 
become  proficient  as  routers  and  service  clerks  in  four 
weeks  and  six  weeks  respectively.  The  training  period  for 
the  Fleet  Center  Command  VDT  operator  normally  takes 
longer-about  three  months-because  the  major  responsibilites 
such  as  queue  status  control  and  channel  management  are 
essentially  new  functions  unrelated  to  any  prior 
communications  experience  [Ref.  26].  In  order  to  gain  the 
maximum  benefit  from  the  training  and  experience  that  is 
developing  among  the  personnel  currently  assigned  to 
automated  stations,  the  Bureau  of  Naval  Personnel  must  adopt 
a  policy  of  rotating  experienced  personnel  from  one 
automated  site  to  another.  This  presently  is  not  being 
done,  and  any  knowledge  acquired  from  one  tour  is  not  being 
utilized  in  subsequent  assignments.  Additionally,  the 
NAVCOMPASS  sites  are  having  to  accept  personnel  with  no 
background  in  automation  and  indoctrinate  them  with  the 
basics  before  they  can  be  used  effectively. 


D.  NAVCCMPASS/IXS  INTERFACE 


The  satellite  Information  Exchange  Subsystem  (IXS) 
consists  of  three  components:  Common  User  Digital 
Information  Exchange  Subsystem  (CUDIX3) ,  Submarine  Satellite 
Information  Exchange  Subsystem  (SSIXS)  and  Tactical  Data 
Information  Exchange  Subsystem  (TADIXS) .  Programs  for  the 
development  of  the  NAVCOMPARS  system  and  the  satellite 
Information  Exchange  Subsystem  <IXS)  originally  proceeded 
concurrently  but  independently.  One  of  the  objectives  of 
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CUDIXS  is  that  it  have  an  on-line  connection  into  the 
Autodin  network.  With  the  successful  implementation  of 
NAVCOMPARS,  adherence  to  the  principles  of  the  NTAP  dictated 
that  NAVCOHPARS  and  CUDIXS  be  interconnected,  thereby 
eliminating  software  and  hardware  redundancy  and  reducing 
requirements  for  operating  personnel.  Currently,  neither 
TADIXS  nor  SSIXS  has  the  requirement  for  an  on-line  entry 
into  Autodin;  however,  the  procedures  developed  for  the 
NAVCOMPARS/CUDIXS  link  could  be  utilized  in  the  future  with 
SSIXS. 

1 .  CUDIXS 

CUDIXS,  a  store  and  forward  system  using  a 
communications  satellite  to  relay  message  traffic,  is  being 
implemented  as  an  alternative  to  present  high  frequency 
ship-shore-ship  communications.  The  shore  component  is  a 
Network  Control  Station  (NECOS)  which  organizes  its. 
subscriber  ships  into  a  functional  net.  The  NECOS,  in 
conjunction  with  the  satellite  terminal  equipment  and  the 
satellite,  will  provide  teletype  message  capability  to  a 
group  of  sixty  ships.  Of  this  total,  fifty  will  be  smaller 
ships  which  will  be  equipped  with  shipboard  terminals  which 
will  allow  them  to  transmit,  but  not  receive,  message 
traffic  via  satellite  on  the  CUDIXS  channels.  These  ships 
will  receive  all  message  traffic  addressed  to  them  by  means 
of  the  fleet  broadcast.  The  fleet  broadcast  uses  a  separate 
satellite  channel,  and  the  transmissions  will  go  directly 
from  NAVCOHPARS  to  the  satellite  terminal  equipment.  (See 
Figure  2)  .  The  remaining  ten  ships,  designated  ''Special 
Subscribers,"  are  high  volume  users  which  will  have  both  the 
send  and  receive  capability.  (See  Figure  3) .  Employing 
round-robin  network  discipline  to  maintain  control  of  its 
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net  of  ships.  The  shore  station  sends  out  a  subscriber 
transmission  sequence  which  specifies  the  order  in  which 
subscribers  are  to  transmit.  Each  scheduled  network  cycle 
includes  a  transmission  phase  and  a  reception  phase  to/from 
each  active  subscriber.  The  NECOS  will  check  the  status  of 
each  subscriber  to  transmit  or  receive  messages  prior  to 
each  operating  cycle;  by  means  of  intercept  processing,  it 
can  hold  traffic  until  a  subscriber  is  capable  of  receiving. 

The  CODIXS  shore  equipment,  designated 
AN/OSQ-6  4  (V) 2,  is  located  in  the  NAVCOMMSTA  Fleet  Center  and 
utilizes  the  AN-UIK-20  mini-computer  to  accomplish  its 
functions.  NECOS  will  queue  traffic  for  transmission  by 
message  precedence,  automatically  synchronize  modulation  and 
cryptographic  equipment  for  transmission  and  perform  all 
data  transfers  on  the  satellite  link.  After  transmission  i;^ 
completed,  the  shore  station  will  coordinate  the  passing  of 
the  proper  acknowledgements.  Several  short  messages  may  be 
forwarded  to  a  ship  during  one  transmission  cycle,  qr  one 
long  message  may  require  several  cycles  for  completion. 
Ontransmitted  message  portions  are  stored  in  the  buffers  of 
the  NECCS  until  the  next  cycle. 


2 •  Systems  Interface 


The  linking  of  these  two  systems  will  allow  CUDIXS 
subscribers  to  have  access  to  those  functions  which 
NAVCOUPARS  currently  provides  to  OTC,  broadcast  and 
dedicated/full  period  users,  such  as  format  validation  and 
correction,  utilization  of  modified  ACP  126  format  and 
direct  on-line  access  to  two  different  ASCs.  Equipment  and 
operator  savings  will  be  realized  in  that  the  NECOS  does  not 
need  to  maintain  a  separate  Mode  I  terminal  for  entry  into 
Autodin.  A  more  direct  altroute  capability  exists  because 
NAVCOMPARS  Can  reroute  messages  automatically  from  a  poor 
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quality  satellite?  link  to  a  broadcast  or  full  period 
channel.  CUDIXS  subscribers  will  be  able  to  recall  messages 
from  NAVCCaPAES  files  for  up  to  ten  days  on-line  and  six 
months  via  magnetic  tape.  NAVCOHPARS  will  maintain  a 
subscriber  message  number  (SMH)  directory  which  will 
accomodate  a  24-hour  file  of  messages  transmitted  to  each 
subscriber.  This  file  allows  subscribers  to  request  message 
reruns  using  the  SMN  as  a  reference.  Utilization  of  the 
file  capacity  of  NAVCOMPABS  eliminates  the  requirement  for 
separate  message  storage  by  the  NECOS,  thereby  generating 
further  equipment  savings.  NAVCOMPABS  prepares  the 
necessary  statistics  and  reports  for  both  systems.  The 
NECOS  will  control  all  data  transmission  via  the  satellite 
link,  and  the  interconnect  between  the  two  systems  will  not 
impose  any  additional  timing  restrictions  on  the  NECOS,  A 
CUDIXS  shore  station  has  been  installed  at  NAVCOMMSTA 
Norfolk,  but  it  is  still  undergoing  testing  and  evaluation. 
The  interface  between  NAVCOMPABS  and  CUDIXS  has  functioned 
satisfactorily,  but  problems  have  been  encountered  in  the 
shipboard  terminal.  [Bef.  28] 


a.  shore-ship  Message  Flow 


A  message  routed  to  a  CUDIXS  "Special 
Subscriber"  could  enter  the  NAVCOMPABS  from  any  source. 
After  internal  processing  by  the  NAVCOMPABS,  the  message, 
preceded  by  a  header  identifying  the  subscribers  who  are  to 
receive  the  message,  is  queued  by  precedence  to  CUDIXS. 
Upon  successful  delivery  of  the  message  to  all  addees,  the 
NECOS  will  return  a  control  record  to  the  NAVCOMPABS  which 
identifies  the  subscriber’s  SMN,  and  the  NAVCOMPABS  will 
journal  the  message. 
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b.  Ship-Shore  Message  Flow 


Modified  ACP  126  narrative  messages  are  to  be 
transmitted  from  subscribers  to  the  NECOS,  where  the  traffic 
is  queued  by  precedence  to  the  NAVCOMPASS,  After  the  EOM 
indicator  has  b^en  accepted  by  the  NAVCOMPARS,  the  NECOS 
will  generate  a  one  line  acknowledgement  message  to  the 
subscriber.  The  NAVCOMPASS  will  validate/ correct  the 
message  and  route  the  message  as  appropriate. 


E.  DATA  EASE  MAINTENANCE 


The  NAVCOMPARS  data  base  is  composed  of  the  library 
file  of  processed  messages,  the  local  station  internal 
distribution  files  and  those  files  used  to  route  messages. 
Due  to  the  staggered  installation  dates  of  the  various 
NAVCOMPARS  sites,  each  location  was  initially  responsible 
for  development  and  maintenance  of  its  data  base.  Of 
primary  concern  in  the  development  of  the  data  base  was  the 
accuracy  of  the  routing  files,  and  this  section  will  discuss 
only  this  particular  aspect  of  the  NAVCOMPARS  data  base. 


1 .  History  of  the  Common  Source  Routing  File 


One  of  the  key  characteristics  of  NAVCOMPARS  as  a 
tactical  communications  system  was  that  it  would  possess  the 
capability  to  provide  routing  instructions  for  all  traffic 
originated  by  ships,  thereby  alleviating  individual  ships  of 
the  continuing  task  of  maintaining  an  updated  edition  of 
ACP-117,  the  world-wide  routing  indicator  (RI)  list.  Due  to 
the  strict  compliance  with  the  requirement  for 
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standardization  of  hardware  and  software  at  all  NAVCCMPA3S 
sites,  the  capability  existed  for  the  various  NAVCCMPARS 
to  assaae  traffic  handling  functions  for  each  other  during 
periods  of  downtime;  however,  for  this  procedure  to  work 
effectively,  the  previously  individualized  data  bases  also 
needed  to  be  standardized.  Initial  responsibility  for  data 
base  maintenance  was  assigned  to  UAVCOMHSTA  Norfolk,  and 
this  station  began  to  update  the  data  bases  of  all 
NAVCOHPARS  sites  in  September  1974  by  means  of  a  Common 
Source  Routing  File  (CSRF) .  All  routing  indicator  changes 
were  transmitted  to  Norfolk,  and  that  station  prepared  the 
necessary  computer  inputs  to  make  the  required  additions  and 
deletions.  These  inputs  were  then  forwarded  via  card 
traffic  on  a  daily  basis  to  all  other  NAVCOHPARS  stations 
for  file  update  action.  Since  June  1975,  NAVCCHMSTA 
Honolulu  has  acted  as  the  CSRF  Update  Facility  for  the 
Western  Hemisphere,  and  Norfolk  has  retained  responsibility 
for  the  Atlantic  and  Mediterranean  areas.  Norfolk  and 
Honolulu'  receive  identical  update  information  with  which 
they  unilaterally  prepare  the  input  for  the  CSRF.  Prior  to 
further  dispersal  of  this  information,  the  above  stations 
compare  their  data  via  point-to-point  orderwire,  and  any 
conflicts  are  researched  and  immediately  resolved.  After 
all  necessary  corrections  have  been  made,  the  daily  update 
information  is  forwarded  to  the  other  CSRF  subscribers.  The 
actual  udating  of  the  CSRF  is  done  on  the  off-line  file 
system,  and  the  complete  procedure  takes  approximately  four 
hours;  the  new  files  go  on-line  at  OOOlZ  of  every  new  radio 
day.  On-line  VDT  changes  can  be  made  for  immediate  update, 
and  an  average  of  five  of  this  type  are  accomplished  each 
day. 


NAVCOMMSTA  Norfolk  has  thirteen  billets  authorized 
for  data  base  maintenance,  and  NAVCOMMSTA  Honolulu 
operates  its  CSRF  facility  with  approximately  the  same 
number.  Not  only  does  this  procedure  ensure  a  world-wide 
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standard  routing  file,  but  it  also  saves  manpower  resources 
because  the  above  two  stations  are  managing  this  vital 
function  for  the  whole  network.  These  savings  will  be 
increasingly  significant  as  additional  LDMX  stations  a.re 
outfitted  with  N4VC0MPARS  software  and  become  part  of  the 
CSEF. 


2.  Composition  of  Common  Source  Routing  File 


The  CSRF  has  five  component  parts:  ACP  Routing 
Indicator  File,  Ships/Station  Guard  Source  File,  Task  and 
Type  Org-anization  File,  Multiple  Address  Routing  Source  File 
and  the  Alternate  Spelling  Source  File.  The  ACP  Routing 
Indicator  File  contains  the  preferred  spelling  of  a 
command’s  short  title  as  specified  in  NTP-3  and  up  to  four 
RIs  which  can  be  used  for  delivery  via  electrical  means. 
This  file,  which  is  basically  the  information  contained  in 
ACP-117,  is  continually  updated  via  card  input  of  additions 
and  deletions.  As  of  September  1975,  there  were  more  than 
21,900  entries  in  the  ACP  file.  The  Ship/Station  Guard 
Source  File  contains  a  list  of  commands  or  units  by  short 
title  which  are  guarded  for  by  a  host  ship  or  station.  In 
this  way  an  embarked  commander  is  related  to  his  host  ship 
for  broadcast  screening  action.  The  composition  of  Navy 
task  and  type  force  organizations  are  delineated  in  the  Task 
and  Type  Organization  File.  Task  force  designations  may  be 
used  to  address  single  or  multiple  addressees.  That  is,  any 
task  force,  group,  unit  or  element  commander  may  be 
individually  addressed,  but  a  message  addressed  to  a  task 
organization  will  be  automatically  delivered  to  all 
components  of  the  specified  organization.  The  Multiple 
Addressee  Routing  Source  File  is  composed  of  every  Navy  and 
Coast  Guard  collective  and  Address  Indicating  Group  (AIG) , 
as  well  as  many  collectives  and  AIGs  of  the  other  services. 
The  only  file  prepared  by  the  individual  stations  is  the 
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Alternative  Spelling  Source  File.  This  copsists  of  coiamon, 
abbreviations  or  misspellings  of  primary  short  titles  in  the 
ACP  file,  and  its  function  is  to  relate  the  misspelled  short 
title  tc  the  correct  routing  indicator.  The  last  four  files 
are  maintained  on  magnetic  tape  with  the  daily  update  being 
accomplished  via  card  changes  being  processed  simultaneously 
with  the  running  of  the  old  tape  to  produce  an  entirely  new 
tape. 


3 .  Problems  of  the  Common  Source  Routing  File 


The  main  difficulties  encountered  by  IIAVCCHMSTA 
Honolulu  in  managing  the  CSRF  are  in  obtaining  timely  and 
accurate  change  information  from  applicable  commands. 
Improper  submission  of  data  has  resulted  in  confusion  in 
maintaining  a  complete  Task  and  Type  Organization  File. 
Lower  eschelon  commands  have  requested  that  they  be  added  or 
removed  from  an  organization  listing  without  proper 
authorization  from  the  cognizant  commander.  The  situation 
has  left  the  CSRF  facility  with  the  burden  of  resolving  the 
conflicting  data  in  order  that  its  files  will  be  accurate. 
RAVCOUHSTA  Honolulu  has  engaged  the  support  of  CINCPACFLT 
in  this  matter,  and  two  messages  addressed  to  all  pacific 
fleet  commands  have  been  issued  which  specify  that  the  task 
or  type  force  commander  has  the  responsibility  to  provide 
the  CSRF  facility  with  the  breakdown  of  its  components.  Any 
contradictory  information  will  be  referred  back  to  the 
applicable  commander  for  resolution.  [Ref.  22] 

Another  problem  involves  the  necessity  for  periodic 
and  complete  validation  of  the  composition  of  collectives 
and  AIGs.  Disestablished  commands  are  still  carried  in 
certain  AIGs  and  collectives  simply  because  the  cognizant 
authority  has  neglected  to  remove  the  outdated  information. 
The  CSRF  facility  can  not  cancel  an  AIG  or  delete  data,  even 
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if  it  knows  such  information  is  erroneous.  The  cognizant 
authority  must  do  its  job  responsibly  in  purging  the  system 
of  extraneous  and  incorrect  information. 

One  minor  problem  area  at  present  which  could  cause 
major  difficulties  in  the  future  is  the  inclusion  of  other 
service  short  titles  in  the  NAVCOaPARS  data  base.  Army 
and  Air  Force  AIGs  and  collectives  with  even  one  Navy, 
Marine  Corps  or  Coast  Guard  addee  must  be  included  in  their 
entirety.  The  Navy  has  expended  a  great  amount  of  effort  in 
the  past  several  years  in  order  to  standardize  short  titles 
in  preparation  for  communications  automation.  The  Army  and 
Air  Force  have  done  little  to  document  and  distribute 
preferred  short  titles  for  their  commands;  consequently,  the 
individual  command  may  itself  use  several  alternate 
spellings  for  its  command  designator.  Any  variation  in  short 
title  which  is  not  anticipated  with  an  entry  in  the 
Alternate  Spelling  Source  File  will  require  manual 
intervention,  thereby  negating  a  major  portion  of  the 
advantage  of  automation.  Unless  the  initiative  is  taken  by 
the  Army  and  Air  Force  to  develop  standardized  short  titles, 
extending  NAVCOMPARS  capabilities  to  other  military  users 
could  result  in  degradation  of  the  system. 
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IV.  MODEL  OF  CENTB AL  PROCESSING  DNIT 


The  section  on  traffic  flow  pattern  of  the  NAVCOMPARS 
in  the  previous  chapter  described  the  functions  of  the 
NAVCOMPARS  subsystems  in  general  terms;  this  chapter  will 
emphasi2e  those  major  program  modules  within  each  subsystem 
which  most  directly  affect  message  processing.  Modules 
which  direct  error  routines  or  handle  special  situations 
are,  for  the  most  part,  neglected  in  order  to  give  a 
comprehensive  and  straightforward  description  of  routine 
message  processing.  The  individual  user  retains  a 
substantial  amount  of  control  over  system  performance 
through  his  compliance,  or  lack  thereof,  with  prescribed 
format  requirements.  The  objective  of  this  chapter  is  to 
create  a  model  of  the  message  processing  sequence  within  the 
NAVCOMPARS  CPU  in  sufficient  detail  to  establish  an 
awareness  of  and  an  appreciation  for  the  format  precision 
which  is  necessary  for  an  automated  system  to  operate  at  its 
full  potential. 

The  means  utilized  by  this  thesis  to  accomplish  the 
above  objective  will  be  to  follow  a  typical  message  through 
the  NAVCOMPARS;  a  flowchart  model  with  narrative  comments 
will  trace  the  progress  of  one  message  through  the  message 
processing  sequence.  In  order  to  demonstrate  the  full 
tactical  potential  of  the  system,  the  following  scenario  has 
been  selected;  A  ship  at  sea  transmits  a  routine  message  in 
modified  ACP  126  format  via  HF  radio  to  the  nearest 
NAVCOMMSTA  for  entry  into  Autodin  and  forwarding  to  a 
command  in  the  Washington  D.  C.  area.  (Step  1,  Figure  6] 
Figure  4  presents  the  sample  message,  and  Figure  5  explains 
the  function  and  structure  of  each  format  line. 
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F/L  1 

F/L  2 

F/L  3 

F/L  4 

F/L  5 

F/L  6 

F/L  7 

F/L  8 

F/L  9 

F/L  10 

F/L  11 

F/L  12 

F/L  13 

F/L  14 

F/L  15 

F/L  16 


VZCZCABC127 

RTTUZYUW  RUEBABC0034  35(31710— RUHPSUU . 

ZNR  UUUUU 
R161710Z  DEC  75 
FM  USS  NEVERSAIL 
TO  CHNAVPERS  WASHINGTON  DC 
INFO  CINCLANTFLT  NORFOLK  VA 


BT 

UNCLAS 

TEXT 

BT 

#0034 

NNNN 


Figure  4  -  SAl-lPLE  MODIFIED  ACP  126  MESSAGE 


FORMAT  LINE 


ELEMENTS 


EXPLANATION  OF  SAMPLE  MESSAGE  CHARACTERS 


F/L  1 


F/L  2 


F/L  3 
F/L  4 


F/L  5 

F/L  6 
F/L  7 
F/L  8 
F/L  9 
F/L  10 
F/L  11 
F/L  12 
F/L  13 
F/L  14 
F/L  15 
F/L  16 


Handling  instructions  V-Ensures  subsequent  intelligence 

not  garbled 

ZCZC-Start  of  message  indicator 
ABC-Station/channel  designator  (CID) 
127-Channel  sequence  number  (CSN) 

Header  R-Precedence :  ROUTINE 

TT-Language  and  Media  Format  (LMF) : 
TELETYPE 

U-Classification:  UNCLASSIFIED 

ZYUW-  Communication  Action  Identifier 

(CAI) :  THIS  IS  A  NARRATIVE  MESSAGE 

RUEBABC-Originating  Station  Routing  Indicator 
(OSRI) 

0034-Station  serial  number  (SSN) 

350-Julian  date 
1710-Time  of  file  (TOF) 

UUUU-Classification  redundancy 
RUHPSUU-Destination  routing  indicator;  SPECIAL 
NAVCOMPARS  RI  ENDING  IN  SUU 
Period-End  of  routing  symbol 

Calling  Station 

and  filing  time  NOT  USED 

Transmission  ZNR-Security  prosign 

Instructions  UUUUU-Classification  designation; 

UNCLASSIFIED 


Precedence  R-Precedence;  ROUTINE 

&  DTG  161710Z  DEC  75-Date  time  group  (DTG) 

Originator  USS  NEVERSAIL 

Action  Addressee  CHNAVPERS 

Information  Addressee  CINCLANTFLT 

Exempted  Addressee  NOT  USED 

Accounting  Information  NOT  USED 

Separation  BT-Separates  heading  from  text 

Text  UNCLAS-Classification 

Separation  BT-Separates  text  from  end  of  message 

NOT  USED  IN  TAPE  RELAY  PROCEDURES 


EOM  Validation  #0034-Station  serial  number 

EOM  Function  NNNN-Proceeded  by  2  carriage  returns  and 

eight  line  feeds 


Figure  5  -  EXPLANATION  OF  MODIFIED  ACP  126  FORMAT 


A.  INITIAL  lEOCESSING 


Upon  receipt  by  the  NAVCOMMSTA  Fleet  Center,  the 
message  is  visually  screened  by  operating  personnel  to 
ensure  that  the  message  is  of  sufficient  quality  (no  garbles 
in  heading  or  text)  for  entry  into  the  NAVCOMPARS.  [Step  2, 
Figure  6]  The  paper  tape  copy  is  then  manually  run  through  a 
paper  tape  reader  which  introduces  the  message  directly  into 
the  system,  [Step  3,  Figure  6]  The  Communications  Control 
Subsystem  (CCS)  is  a  software  package  which  provides  the 
necessary  support  functions  to  coordinate  the  system's 
peripheral  equipment  to  the  message  processing  subsystems. 
In  this  specific  instance,  CCS  allows  the  paper  tape  reader 
to  generate  input  to  the  Receive  Control  Subsystem  so  that 
the  sample  message  is  queued  for  the  Receive  Control  Format 
Exchange  Jlodule  (RCFX) .  [Step  4,  Figure  6] 


1 .  Receive  Control  Format  Exchange  Module  (RCFX) 


The  primary  functions  of  RCFX  are  to  convert  the 
narrative  character  codes  of  the  various  message  input 
devices  into  a  common  character  code  and  then  to  divide  the 
input  stream  into  proper  length  file  segments  for  recording 
on  the  recovery  disk?.  For  the  sample  message,  the 
five-level  baqdot  code  used  by  the  paper  tape  reader  is 
translated  into  EBCDIC  to  facilitate  processing  within  the 
CPU.  The  shift  characters  of  the  teletype  are  set  to  null 
characters,  and  carriage  returns  and  line  feeds  are  deleted. 
RCFX  identifies  format  lines  1,  2,  11,  13,  15  and  16  of 
every  message.  Line  analysis  is  accomplished  by  a  series  of 
subroutines,  each  of  which  analyzes  a  specific  line.  Entry 
to  the  appropriate  subroutine  is  gained  by  using  an 
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STEP  1 


USS  NEVERSAIL 


STEP  2. 


STEP  3. 


STEP  4. 


QUEUE  FOR 
INITIAL 
PROCESSING . 


STEP  5. 


RCFX 


HEADER  ANALYSIS 
AND 

CODE  CONVERSION 


STEP  6. 


Figure  6  -  MESSAGE  INPUT  AND  INITIAL  PROCESSING 


index  to  an  address  table  of  all  line  analysis  subroutines. 
For  this  message,  the  index  is  set  to  format  line  one;  as 
each  format  line  is  identified,  the  index  is  set  to  the  next 
line  analysis  processor,  but  the  index  will  not  be  bumped  to 
the  next  subroutine  until  the  line  currently  being  sought  is 
found.  If  format  line  two  is  not  validated,  the  message  is 
rejected,  and  a  rejection  notice  is  built.  The  format  of 
the  sample  message  is  assumed  to  be  validated  as  correct, 
and  the  message  is  assembled  into  file  segments  for  the 
Recovery  Disk  (RCDSK) .  RCFX  begins  the  process  of  building 
a  Summary  Data  Area  (SDA)  for  each  message.  As  each  format 
line  is  identified,  applicable  information  such  as  the 
CDCSN,  precedence  code,  input  device  symbol,  OSfll,  SSN,  and 
numerics  of  straggler  check  are  transferred  to  the  SDA. 
[Step  5,  Figure  6] 


2*  Receive  Control  Input/Output  Modu^  fRCIO) 

The  function  of  RCIO  is  to  accomplish  the  dual 
recording  of  message  information  on  the  Recovery  Disks 
(RCDSK)  which  are  resident  on  on-line  magnetic  disk  packs- 
The  information  recorded  on  each  RCDSK  consists  of  certain 
line  defining  information,  actual  material  from  the  message, 
data  linking  instructions  and  some  message  handling 
information.  The  inputs  to  RCIO  include  the  message 
segments  and  SDA  generated  in  RCFX,  and  processing  of  this 
information  falls  in  three  categories:  start,  middle  and 
end  of  message.  Start  of  message  processing  is  designed  to 
initiate  the  disk  address  linkages  for  the  entire  message 
prior  to  the  writing  of  the  RCDSK.  Kiddle  processing 
handles  continuation  linkages  for  the  message  and  then 
writes  the  message  on  both  Recovery  Disks.  End  of  message 
processing  incorporates  the  SDA  into  the  final  section  and 
adds  finalization  linkages  as  necessary.  [Step  6,  Figure  6] 
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B.  MESSAGE  FEOCESSING  SUBSYSTEM 


The  ECS/KPS  Interface  Table  is  core-resident  in  the 
Common  Data  Area,  and  it  is  used  as  a  means  of  communication 
between  the  two  subsystems.  After  the  HCDSKs  have  been 
written  and  ECS  has  a  message  queue  entry  to  pass  to  MPS, 
ECS  will  place  the  ECDSK  pointer,  message  type  and  message 
priority  in  the  interface  table  and  will  set  an  indicator 
requesting  transfer  to  MPS.  [Step  7,  Figure  7]  MPS 
periodically  checks  the  indicator,  and  when  it  is  set,  MPS 
will  enter  the  message  in  its  input  queue  and  set  an 
acknowledgement  indicator  for  ECS  in  the  interface  table  as 
to  the  action  taken.  Processing  for  the  sample  message 
begins  with  the  Common  JAMAP  128  Heading  Analysis  Module. 


1 .  Common  ^ N AP  128  Keadiag  Analysis  Module  ( M-PJA) 


MPJA  operates  on  non-data  pattern  JANAP  128  and 
modified  ACP  126-  messages  with  its  major  function  being  the 
analysis  of  the  heading  up  to  and  including  format  line 
five.  The  processing  includes  format  line  analysis,  routing 
indicator  isolation,  end-of-message  checks  and  straggler 
checks.  A  straggler  is  a  message  which,  because  of  an 
incorrect  end-of-message  function,  either  trails  or  is 
attached  to  the  preceding  message.  Throughout  the 
identification  process,  all  vital  elements  of  information 
are  preserved  in  the  MPS  SDA  for  subsequent  processing.  The 
MPS  SDA  is  a  core  resident  buffer  which  provides  an  area 
where  processing  programs  can  maintain  and  obtain  transient 
data  (such  as  line  counts)  or  provide  pertinent  data  (such 
as  the  station  serial  number  assigned  by  MPJA)  to  fulfill 
other  program's  tasks;  it  is  used  by  all  modules  in  the  MPS 
environment,  with  each  module  updating  specific  fields  as 
the  message  processing  analysis  functions  are  performed. 
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STEP  7. 


STEP  8. 


STEP  9. 


STEP  10 


STEP  11 


Figure  7  -  MESSAGE  PROCESSING  SEQUENCE 
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ilPJA  begins  processing  analysis  by  fetching  the  first  line 
of  a  message  segment  and  testing  it  for  format  line  one;  if 
validated,  this  line  is  transferred  to  the  SDA.  Processing 
then  continues  as  MPJA  fetches  the  next  line  and  validates 
it  element  by  element.  Format  line  two  elements  are 
interrogated  in  the  following  order: 

a.  Precedence  chapacter 

b.  Language  and  Media  Format 

c.  Classification  (The  security  level  is  temporarily 
saved  for  redundant  security  test  with  the  security  field  in 
columns  30-33.) 

d.  Channel  Identification  Code/Command  Action 
Identifier 

e.  Originating  Station  Routing  Indicator  and  Station 
Serial  Number  (Used  for  straggler  check  with  F/L  15) 

f.  Time  of  File 

q.  Security  Field  (This  field  must  agree  with  the 
security  character  saved  from  column  4.) 

h.  Test  for  modified  ACP  126  type  message  (The  BI  in 
the  format  line  is  compared  for  the  special  NAVCOMMSTA  RI 
ending  in  SOU.) 

i.  Period 

If  any  element  is  unable  to  be  validated,  a  display  is 
built  for  the  VDT  operator  indicating  the  error.  The  screen 
will  be  annotated  with  an  error  notation  reading  ••INVALID 
F/L  X"  which  will  be  followed  by  ten  addditional  lines  of 
the  message.  The  VDT  router  can  either  correct  the  line  or 
reject  the  message  to  either  the  Service  Clerk  or  the  Top 
Secret  Courier.  Since  the  sample  message  is  correctly 
formated,  each  element  is  validated  and  then  stored  in  the 
SDA. 


MPJA  continues  to  fetch  each  line  in  turn,  validating 
it  depending  on  the  characteristic  of  that  particular  format 
line.  The  sample  message  has  no  format  line  three; 
therefore,  it  will  next  encounter  the  security  prosign 
(either  "ZNE”  or  "ZNY^^)  in  format  line  four.  '•ZNR''  is  used 
with  unclassified  messages,  while  '•ZNY"  is  used  with  all 
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classifiad  messages  including  those  designated  UMCLAS  EFTO 
(Encrypted  fcr  Transmission  Only).  After  validating  the 
prosign,  ilPJA  will  next  access  the  security  redundancy 
symbols.  Since  the  sample  message  has  the  prosign  ”ZNR”, 
the  only  acceptable  designation  is  the  characters  "UDUOU'* 
representing  an  unclassified  message.  Having  validated  this 
as  correct,  the  routine  compares  format  line  four  security 
to  that  found  in  format  line  two;  if  these  don't  agree,  a 
mismatch  has  occurred,  and  a  display  is  built  fcr  the 
router,  who  can  either  correct  the  line  or  reject  the 
message.  In  scanning  format  line  four,  MPJA  also  searches 
for  precedence,  and  it  enters  format  line  five  processing 
when  it  finds  arguments  which  meet  these  search  criteria. 
In  all  cases  where  a  dual  precedence  exists,  • format  line 
five  will  be  validated  if  the  format  line  two  precedence 
matches  either  the  ACTION  or  INFO  character.  MPJA  then 
searches  for  the  date-time-group,  and,  when  found,  the 
module  moves  the  entire  line  to  the  proper  field  in  the  MPS 
SDA  in  order  to  effect  the  Originator  Date-time-group  File 
update.  If  the  DIG  can  not  be  delimited,  MPJA  causes  a 
display  of  the  message  to  the  router  who  can  assign  or 
correct  the  ODTG  or  reject  the  message  to  the  service  clerk. 
Once  the  entire  line  has  been  processed,  it  is  moved  to  the 
SDA.  In  addition  to  format  line  validation,  MPJA  performs  a 
check  for  Suspected  Duplicate  (SUSDOPE)  messages.  The 
arguments  for  the  0S3I  SSH  search  are  extracted  from  the 
proper  fields  in  the  SDA  and  are  used  for  comparison  against 
the  system's  Originating  Station  Routing  Indicator  file.  If 
the  message  is  a  SDSDUPE,  it  is  rejected  to  the  service 
clerk  and  further  processing  is  terminated.  The  processing 
serial  numbers  of  up  to  seven  previous  duplicates  are 
extracted  frcm  the  file  and  are  appended  as  a  service  line 
in  order  to  facilitate  action  by  the  service  clerk.  MPJA 
waives  the  SDSDOPE  check  for  all  Flash  and  Emergency  Command 
messages.  Once  format  line  five  has  been  entirely 
validated,  MPJA  has  completed  its  processing  on  modified  ACP 
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126  type  messages,  and  it  relinquishes  control.  [Step  8, 
Figure  7]  The  next  module  is  MPFC. 

2.  Message  Processing  Subsystem  ACP  126  Routi^  and 
Format  Conversion  (MPFCl 

MPJA  has  up  to  this  point  constructed  a  model  of 
certain  portions  of  the  JANAP  128  header;  MPFC  continues 
format  line  analysis  with  line  six  and  completes  the 
conversion  from  modified  ACP  126  to  JANAP  128  format.  It 
also  does  paging,  sectioning  and  maintenance  of  continuity 
for  sectioned  messages.  Errors  and  illogical  conditions 
that  arise  during  processing  are  referred  to  a  VDT  operator 
for  resolution.  The  BCDSK  segment  which  contains  format 
line  six  will  already  be  core  resident,  but  MPFC  will  access 
ECDSK  as  many  times  as  necessary  to  read  all  segments 
associated  with  the  message.  [Step  9,  Figure  7]  This  module 
begins  processing  by  reading  the  first  three  characters  of 
the  line  and  testing  them  for  the  argument  '*FM'*.  If  this 
configuration  is  not  identified,  MPFC  causes  a  display  to 
the  router  who  can  correct  the  line.  If  the  first  three 
characters  are  correct,  MPFC  accesses  the  short  title  and 
validates  it. 

The  message  header  is  then  scanned  for  one  of  the 
following  arguments  which  are  positional;  "TO"  or  "INFO". 
When  neither  is  found,  an  error  is  diagnosed  and  a  display 
is  built  for  the  router.  If  "TO"  is  found,  MPFC  goes  into 
format  line  seven  processing  in  order  to  validate  short 
titles  and  assign  routing  indicators.  The  routine  will 
determine  if  a  short  title  is  valid  by  comparing  it  with  the 
information  in  the  Routing  File  Directory  (EOUTFL) ,  which  is 
a  consolidation  of  all  the  on-line  message  processing  files. 
If  a  short  title  can't  be  found  in  the  ROOTFL,  a  display 
will  be  built  for  the  router  indicating  this  fact.  When  the 


52 


short  title  is  validated,  the  routine  then  proceeds  to 
determine  the  routing  indicator.  The  ROUTFL  itself  will 
contain  one  primary  RI,  If  the  HI  thus  obtained  is  not 
cleared  for  the  classification  of  the  message  or  if  a 
collective  routing  is  indicated,  the  processing  routine  will 
extract  a  pointer  from  the  ROUTFL  for  the  ACPFIL  entry  for 
that  short  title  and  the  necessary  routing  indicator  will  be 
accessed  from  that  entry.  [Step  10,  Figure  7] 

Once  the  format  line  seven  processing  has  been 
accomplished,  MPPC  initiates  a  program  scan  for  the  next 
processing  event.  If  ’’INFO"  is  encountered,  the  routine 
utilizes  format  line  eight  processing  which  is  identical  to 
F/L  7.  When  ’’XaT”  is  detected,  MPFC  takes  action  to  remove 
the  exempted  addressee  from  any  collective  routing 
indicators.  The  sample  message  has  no  format  line  ten,  so 
the  next  event  validated  by  MPFC  will  be  the  ”BT”  in  format 
line  eleven.  After  the  *'BT'*  has  been  framed  and  moved,  the 
programming  module  begins  text  processing  with  format  line 
twelve.  MPFC  will  examine  the  security  narrative  in  this 
line  and  will  determine  if  it  matches  the  security  warning 
found  in  both  format  lines  two  and  four.  If  the  security 
narrative  does  not  agree,  a  mismatch  has  occurred,  and  MPFC 
will  build  a  display  to  the  router  for  the  resolution  of 
this  error  condition.  Any  special  handling  instructions  are 
identified  and  validated.  After  the  security  and  special 
handling  criteria  have  been  processed,  MPFC  tests  the 
message  line  count  to  determine  if  this  will  be  a  sectioned 
message.  Messages  are  sectioned  only  if  they  exceed  five 
pages  or  100  lines  of  text  from  format  line  twelve.  In 
order  to  ascertain  the  number  of  sections  for  long  messages 
which  meet  the  above  criteria,  MPFC  substracts  the  number  of 
lines  found  from  F/L  2  to  F/L  11  from  the  total  message  line 
count.  The  result  is  divided  by  twenty  to  determine  the 
number  of  pages;  this  figure  is  then  divided  by  five  to 
arrive  at  the  number  of  sections. 
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reference  lines 


During  text  processing,  reference  lines  and 
paragraph  lines  are  searched  for  and  identified  for  any 
necessary  subseguent  processing.  After  the  textual  portion 
of  the  message  has  been  processed,  HPFC  completes  the  JANAP 
128  header  in  the  SDA  by  attaching  the  routing  indicators 
for  format  line  two.  MPFC  sorts  these  indicators  in  binary 
ascending  order  and  then  moves  them  to  the  MPS  SDA. 
Duplicate  RIs  are  not  moved  and  are  thus  eliminated  from 
inclusion  in  the  header.  After  the  header  and  routing 
information  have  been  supplied  and  all  necessary  linkages 
between  text  segments  and  these  elements  have  been  effected, 
the  message  is  redundantly  written  on  the  Message  Processing 
Disk  (MPDISK) ;  the  data  contained  on  this  disk  is  the  output 
image  of  the  message.  [Step  11,  Figure  7]  MPFC  then  causes 
the  message  to  be  queued  to  the  Transmission  Processing 
Subsystem  (TPS) ,  thus  completing  an  input  transaction. 
[Step  12,  Figure  10]  Figure  8  is  the  output  version  of  the 
sample  message  in  JANAP  128  format.  Pertinent 
characteristics  of  this  format  have  been  explained  in  Figure 
9. 


C.  TRANSMISSION  PROCESSING 


The  remaining  NAVCOHPARS  subsystems  handle  the  message 
transmission  and  journaling  functions.  The  modules  of  the 
Transmission  Processing  Subsystem  (TPS)  deal  with  the 
message  queuing  functions,  while  the  modules  of  the 
Transmission  Control  Subsystem  (TCS)  supervise  channel 
activation  and  message  delivery.  As  the  sample  message  will 
be  relayed  to  its  ultimate  destination  via  the  Autodin 
system,  the  Autodin  Control  Subsystem  (ACS)  is  the  final 
subsystem  thru  which  the  message  must  traverse. 
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F/L  1 

F/L  2 

F/L  3 

F/L  4 

F/L  5 

F/L  6 

F/L  7 

F/L  8 

F/L  9 

F/L  10 

F/L  11 

F/L  12 

F/L  13 

F/L  14 

F/L  15 

F/L  16 


VZCZCXYZ066 

RTTUZYUW  RUHRSVCi3321  3501710-UUUU— RUWMFDA  RUCLBEA. 

ZNR  UUUUU 
R161710Z  DEC  75 
FM  USS  NEVERSAIL 

TO  RUWMFDA/CHNAVPERS  WASHINGTON  DC 
INFO  RUCLBEA/CINCLANTFLT  NORFOLK  VA 


BT 

UNCLAS 

TEXT 

BT 

#0321 

NNNN 


Figxire  8  -  SAMPLE  OF  JANAP  128  MESSAGE 
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FORMAT  LINE 


ELEMENTS 


EXPLANATION  OF  SAMPLE  MESSAGE  CHARACTERS 


F/L  1  Handling  Instructions  V-Ensures  subsequent  intelligence 

not  garbled 

ZCZC-Start  of  message  indicator 
XYZ-Station/channel  designator  (CID) 
066-Channel  sequence  number  of  NAVCOMMSTA 
F/L  2  Header  R- Precedence:  ROUTINE 

TT-Language  and  Media  Format:  TELETYPE 
(Repeats  LMF  of  original  modified 
ACP  126  message) 

U-Classification;  UNCLASSIFIED 
ZYUW-Communication  Action  Identifier: 

THIS  IS  A  NARRATIVE  MESSAGE 
RUHRSVC-Origination  Station  Routing  Indicator: 
ROUTING  INDICATOR  FOR  THE  NAVCOMMSTA 
SERVICE  CENTER  IS  USED  AS  THE  OUTGOING 
RI  ON  NAVCOMPARS  MESSAGES 
0321-Station  Serial  Number:  SUPPLIED  BY 
NAVCOMPARS 
350-Julian  date 
1710-Time  of  file 
UUUU-Classification  redundancy 
RUWMFDA-Destination  routing  indicator 
RUCLBEA-Destination  routing  indicator 
Period-End  of  routing  symbol 


F/L  3 

NOT  USED 

F/L  4 

Transmission 

ZNR- Security  prosign 

Instructions 

UUUUU-Classification  designation: 

UNCLASSIFIED 

F/L  5 

Precedence 

R-Precedence :  ROUTINE 

&  DTG  161710Z 

DEC  75-Date  time  group 

F/L  6 

Originator 

USS  NEVERSAIL 

F/L  7 

Destination  RI 

RUWMFDA/CHNAVPERS 

&  Action  Addressee 

F/L  8 

Destination  RI 

RUCLBEA/CINCLANTFLT 

&  Information  Addressee 

F/L  9 

Exempted  Addressee 

NOT  USED 

F/L  10 

Accounting  Information  NOT  USED 

F/L  11 

Separation 

BT-Separates  heading  from  text 

F/L  12 

Text 

UNCLAS-Classification 

F/L  13 

Separation 

BT-Separates  text  from  end  of  message 

F/L  14 

NOT  USED 

F/L  15 

EOM  Validation 

#0321-NAVCOMPARS  Station  serial  number 

F/L  16 

EOM  Function 

NNNN- Proceeded  by  2  carriage  returns  and 

eight  line  feeds 


Figure  9  -  EXPLANATION  OF  JANAP  128  FORMAT 


56 


Once  the  message  has  been  processed  by  ACS,  the  sample 
message  has  ccmpleted  the  NAVCOMPARS  cycle. 

When  the  sample  message  comes  under  the  responsibility 
of  IPS,  the  initial  module  which  assumes  control  is  the 
Transmission  Processing  Queue  Handler. 


•  Iransmission  Processing  Queue  Handler  (TPQK) 


TFQH  is  the  module  which  manages  all  queuing 
functions,  as  well  as  other  related  tasks  such  as  checking 
for  message/line  security  mismatches  and  the  generation  of 
queuing  statistics.  In  order  to  fully  understand  the 
procedures  utilized  by  TPQH,  several  terns  must  be 
identified  and  defined.  A  bit  map  is  included  in  the  SDA 
for  each  message;  the  intended  destinations  of  each  message 
are  indicated  by  whether  predetermined  bits  are  placed  in  an 
“on"  condition.  Initially,  two  maps  are  creq.ted.  The 
original  remains  intact,  but  the  duplicate  is  modified  and 
updated  as  each  individual  delivery  is  made.  Files  labelled 
Destination  Control  Blocks  (DCB)  are  maintained  in  core 
memory  for  each  outgoing  channel  and  electronic  courier 
circuit.  TPQH  is  structured  to  utilize  two  separate  queues 
for  each  message.  A  message  queue,  designated  Q1 ,  contains 
an  entry  for  each  individual  message  processed  by  the 
system.  The  information  contained  in  the  Ql  entry  includes 
the  following:  a  transmission  count  giving  the  number  of 
destinations  for  the  message,  a  pointer  to  the  location  of 
the  message  og  the  ECDSK,  a  pointer  to  the  location  of  the 
message  on  the  HPDISK,  the  code  for  message  type,  and  the 
processing  priority  assigned  to  the  message.  A  pointer  is  a 
link  between  one  record  and  another  in  that  a  field  in  the 
first  record  indicates  the  location  on  the  storage  devices 
of  the  second  record.  The  other  queue  is  the  transmission 
queue,  kncwn  as  Q2 ,  which  functions  as  a  storage  area 
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STEP  12. 


QUEUE 

FOR 

TPS 


STEP  13. 


TPQH 

CREATE 

Q1 

ENTRY 


STEP  16. 


Figure  10  -  TRANSMISSION  PROCESSING 
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for  pointers  to  message  entries  in  Q1.  Each  Ql  entry  has 
corresponding  Q2  entries  for  each  Destination  Control  Block 
to  be  utilized  to  effect  delivery.  The  information  included 
in  each  Q2  entry  consists  of  a  pointer  referencing  the 
relative  position  of  the  applicable  Ql  entry  and  a  pointer 
linking  the  Q2  entry  to  the  next  Q2  entry  for  this 
particular  DCB.  Within  Q2^  all  entries  for  a  particular  DCB 
are  linked  together  by  processing  precedence. 

The  sequence  of  events  involving  the  above 
components  is  begun  when  message  information  from  MPS  is 
enqueued  to  Ql  and  e  Ql  entry  is  created.  [Step  13,  Figure 
10]  The  bit  maps  of  this  message  are  examined  to  determine 
all  the  destinations.  Once  a  destination  is  identified, 
TPQH  will  match  the  security  classification  of  the  message 
against  that  of  the  destination  channel.  If  a  mismatch  has 
occurred,  the  message  will  be  diverted  to  the  Top  Secret 
courier  and  a  service  message  delineating  the  error  will  be 
created.  [Step  14,  Figure  10]  Otherwise,  Q2  pointers  and  Q2 
entries  will  be  created,  and  the  Q2  entry  will  be  linked  to 
the  appropriate  DCB,  [Step  15,  Figure  10]  When  the  message 
reaches  the  head  of  the  queue,  the  Q2  pointer  will  be  used 
to  access  the  Q2  entry,  which  in  turn  provides  the  Ql 
pointer  to  access  the  Ql  entry.  The  Ql  entry  then  leads 
back  to  the  output  image  of  the  message  on  the  aPDISK,  and 
this  is  read  for  transmission.  After  transmission 
acknowledgement,  the  Q2  entry  is  dequeued.  Subsequent  to 
message  journalization,  the  Ql  entry  is  dequeued. 

Other  functions  performed  by  TPQH  are  involved  with 
overall  queue  management  and  recording  of  statistics.  The 
module  maintains  queuing  counts  by  precedence  for  each 
destination  channel  or  courier  circuit,  and  it  will  notify 
the  Fleet  Center  VDT  operator  by  means  of  a  service  notice 
whenever  pre-established  thresholds  are  exceeded. 
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Additionally,  TPQH  totals  queue  statistics  for  each  radio 
day. 


2-  Iransffljssion  Control  Line  Program  (TCLP) 

TCLP  is  a  module  of  the  Transmission  Control 
Subsystem,  and  its  main  functions  are  to  monitor  the  status 
of  individual  channels  and  to  begin  message  transmission 
when  channels  are  activated.  TCLP  will  access  the  DCS  to 
receive  the  next  queue  entry  from  TPQH.  Another  check  will 
be  run  by  TCLP  to  validate  that  the  line  security  level  is 
equal  to  or  greater  than  the  message  classification. 
Messages  will  be  rejected  to  the  Top  Secret  courier  if  this 
test  is  failed.  Upon  completion  of  delivery,  TCLP  will 
instruct  TPS  of  this  fact  and  will  provide  the  applicable 
channel  sequence  number. 

Because  the  sample  message  will  be  entered  into  the 
Autodin  network,  additional  processing  steps  are  required. 
Determination  must  be  made  as  to  which  Autodin  Switching 
Center  will  receive  the  message;  the  message  will  be  sent  to 
the  primary  switch  if  it  is  available  and  otherwise  to  the 
secondary  switch.  The  primary  switch  is  the  one  designated 
to  handle  the  greater  number  of  routing  indicators,  TCLP 
will  access  the  MPDISK  to  obtain  the  message  data  for 
transmission,  but  any  previously  recorded  format  line  one 
will  be  deleted.  The  programming  routine  adds  the  necessary 
upshifts,  downshifts,  carriage  returns  and  line  feeds,  and 
then  converts  the  message  into  ASCII  code  for  the  outgoing 
Autodin  line.  The  message  data  is  then  placed  in  the 
Autodin  Transmit  buffer  for  transfer  to  the  Autodin  Control 
Subsystem.  [Step  16,  Figure  10] 
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3. 


Autodin  Control  Module  ( ACS) 


This  module  links  the  Series  70/45  processor  to  the 
two  70/160Q  Autodi^  terminals,  one  for  each  Autodin 
Switching  Center.  TCS  will  notify  ACS  when  an  outgoing 
message  has  been  stored  in  the  Autodin  Transmit  buffer,  and 
ACS  will  retreive  the  message  segments  and  transmit  them  to 
the  appropriately  designated  1600  processor.  ACS  receives 
acknowledgement  of  message  receipt  from  the  1600  processor 
and  passes  this  acknowledgement  back  to  TCS.  [Step  17, 
Figure  11] 


4 .  Transmission  Processing  Message  Journal  Module 


TPMJ  accomplishes  the  journal  entries  for  every 
message  that  is  processed  by  NAVCOMPARS.  All  messages  are 
written  on  the  Journal  Tape  File;  this  file  is  stored  on 
magnetic  tape,  and  each  message  is  kept  for  six  months. 
Additionally,  a  journal  file  of  all  over-the-counter  traffic 
is  maintained  on  disk  for  approximately  thirty  days.  TPMJ 
does  journalizing  action  on  a  timed  interval  of  every  three 
minutes  or  whenever  ten  messages  are  waiting  in  the  journal 
gueue.  [Step  18,  Figure  11] 
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STEP  17 


TRANSMIT 

TO 

AUTODIN 


STEP  18. 


TPMJ 

WRITE  TO 
MESSAGE 
JOURNAL  TAPE 


Figure  11  -  MESSAGE  JOURNALIZATION 


V. 


CONCLUSION 


This  thesis  has  delineated  the  major  procedures  involved 
in  processing  messages  traffic,  as  well  as  examined  various 
related  system  aspects  such  as  training  and  data  base 
management.  The  emphasis  of  this  paper  has  focused  on 
providing  a  basic  understanding  of  N&VCOMPARS  and  its 
associated  procedures  as  they  exist  today.  The  intent  was 
to  produce  a  document  which  could  be  used  as  an  orientation 
text  for  personnel  upon  initial  contact  with  an  automated 
communications  system. 

The  manager  in  $.  communications  environment  must  be 
involved  with  the  total  system-with  both  human  and  non-human 
elements.  Because  NAVCOMPASS  is  currently  operational, 
the  equipment  and  the  pre3cribed  message  procedures  are 
fixed  in  the  short-run.  Therefore,  immediate  improvements 
in  message  handling  efficiency  can  only  be  obtained  by 
gaining  the  support  and  dedication  of  the  personnel 
utilizing  the  system  and  stimulating  them  to  tetter 
performance.  In  the  long  run,  equipment  and  procedures  can 
be  modified  in  an  effort  to  upgrade  the  system.  The 
concluding  section  of  this  thesis  will  discuss  some 
background  which  affected  system  development  and  will 
present  projected  modifications  of  NAVCOMPARS. 

A.  HARDWARE 

The  heart  of  NAVCOMPARS  is  the  ONIVAC  Series  70/45 
<formerly  RCS  Spectra  70/45)  central  processing  unit.  This 
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computer  was  procured  through  competitive  formally 
advertised  procedures  and  was  selected  as  the  CPU  which  met 
the  technical  specifications  and  which  was  most  cost 
effective.  [Eef.  24]  RCA  brought  out  the  Spectra  70  series 
of  computers  at  the  end  of  1964  as  a  competitor  to  the  newly 
introduced  IBM  360  family.  Even  though  the  Spectra  70s  were 
estimated  to  be  priced  at  40%  of  the  cost  of  the  comparable 
IBM  360s,  they  did  not  make  a  significant  impact  on  IBM's 
market.  In  1970  the  RCA  computer  division  chief 
re— introduced  the  Spectra  70  series  and  cut  prices  further 
to  attract  business.  As  a  result  of  inefficient  management 
within  its  computer  division,  RCA  left  the  computer  industry 
in  1971  and  sold  its  base  of  customers  to  the  UNIVAC 
division  of  Sperry  Rand.  [Eef.  J]  Since  1  January  1972  the 
Navy  has  received  service  on  its  Series  70/45s  from  UNIVAC. 
The  NAVCOMPARS/LBMX  computer  equipment  was  leased  up  until 
August  1975  when  the  decision  was  made  to  buy  the  existing 
installations.  [Hef.  21]  Difficulty  has  been  encountered  in 
that  the  Series  70/45  has  reached  the  limit  of  core  memory 
that  the  system  can  handle.  The  original  core  memory 
consisted  of  252,144  (8  bit)  bytes.  [Ref.  28]  This  capacity 
has  been  doubled  through  the  addition  of  boxes  of  core 
memory.  The  implementation  of  additional  functions  on  the 
NAVCOHPABS  will  have  to  be  delayed  pending  the  acquisition 
of  the  follow-on  CPU  with  its  expanded  core  memory.  The 
decision  has  been  reached  to  procure  the  UNIVAC  90/60'  as  the 
folioH-cn  to  the  Series  70/45.  The  90/60  system  will  have  a 
maximum  of  1,048,000  bytes  of  core  memory  and  will  be  able 
to  support  planned  system  enhancements  such  as  the 
consolidation  of  special  intelligence  and  general  service 
traffic  within  a  single  processor.  The  90/60  processor  will 
be  installed  at  NAVCOMPARS  sites,  while  the  Navy-owned 
70/45s  will  be  split  apart  and  used  to  back  fit  projected 
LDMX  locations.  As  an  LDMX  utilizes  only  one  CPU,  each 
upgraded  NAVCOMPARS  can  provide  a  70/45  for  two  LMDX  sites. 
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Another  hardware  problem  has  revolved  around  the 
peripherial  equipment  utilized  for  file  storage.  The 
original  equipment  configuration  included  a  Mass  Storage 
Unit  which  recorded  data  on  magnetic  cards  and  could  contain 
up  to  45  days  worth  of  message  traffic.  This  unit  proved  to 
be  mechanically  unreliable,  and  its  access  time  was 
relatively  slow.  In  order  to  alleviate  these  conditions, 
the  Mass  Storage  Units  are  being  replaced  by  a  Direct  Access 
Disk  Storage  (DADS)  system  which  will  be  faster  and  more 
reliable.  The  message  file  capacity  will  be  reduced  to 
approximately  twenty-five  days  worth,  which  will  be  employed 
for  reference  routing  for  over-the-counter  traffic.  [Refs. 
21  and  24}  The  installation  of  the  DADS  in  Honolulu  has 
provided  an  excellent  illustration  of  the  necessity  of 
evaluating  the  total  situation.  The  maintenance  of  a 
constant  physical  environment,  especially  in  regard  to 
temperature,  is  a  critical  factor  in  the  operation  of  a 
computer  system.  When  the  DADS  was  installed,  the  result 
was  a  modification  of  the  heat  load  in  the  computer  area- 
This  heat  imbalance  began  to  cause  problems  in  performance 
of  the  system's  perpherial  equipment,  such  as  disk  drive 
heads.  In  order  to  rectify  the  difficulty,  the  computer 
room  air  conditioning  was  re-ducted  at  the  cost  of  $10,000. 
A  computer  system  is  a  delicately  balanced  entity,  and  all 
aspects  of  its  operation  and  maintenance  must  be  carefully 
examined  and  evaluated  prior  to  the  implementation  of 
changes.  Adequate  preplanning  can  prevent  problems  and 
outages. 

B.  CODE  TRANSLATION 

Code  translation  is  the  term  used  to  describe  the 
process  whereby  the  code  used  by  terminal  devices  is 
converted  into  the  code  utilized  by  the  central  processor. 
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The  extensive  use  of  this  process  could  be  considered  a 
source  of  major  inefficiency  of  the  current  structure  of 
NAVCOMPAHS.  In  its  effort  to  compete  with  IBM,  RCA  designed 
its  spectra  70  series  to  employ  the  same  instructions, 
formats  and  character  codes  as  the  IBM  360.  [Ref.  3]  The 
result  of  this  is  that  the  70/45  CPU  utilizes  EBCDIC  as  its 
internal  processing  code.  In  contrast,  the  major 
communications  code  employed  by  the  federal  government  on 
its  lines  is  ASCII. 

Between  1959  and  1962,  the  7-level  code  designated  ASCII 
was  developed  in  order  to  provide  some  means  of  standardized 
coding  capability  between  products  of  various  computer 
manufacturers.  IBM,  realizing  that  standardization  between 
processors  might  cut  into  its  dominant  position,  voted 
against  the  adoption  of  ASCII  as  a  standard.  Instead,  it 
developed  an  8-level  code,  EBCDIC,  which  it  utilized  for  the 
IBM  360  series.  This  code  was  adopted  by  other 
manufacturers,  including  RCA  for  its  Spectra  70  series.  The 
federal  government  was  a  major  supporter  of  the  movement  to 
designate  ASCII  as  an  official  standard;  to  give  impetus  to 
this  development.  President  Johnson  in  1968  released  a 
memorandum  establishing  ASCII  as  a  federal  standard.  All 
computers  brought  into  the  government  inventory  after  1  July 
1969  were  required  to  have  the  capability  to  use  ASCII.  In 
an  effort  to  prevent  ASCII  from  becoming  the  only  standard, 
IBM  endeavored  to  limit  ASCII  to  being  recognized  only  as  a 
communications  standard.  In  1969  the  strict  position  of 
President  Johnson  was  modified,  and  the  government  directed 
that  ASCII  was  required  only  for  communications.  The 
mandatory  use  of  ASCII  as  an  internal  processing  code  could 
be  waived  by  an  agency  head  if  efficiency  could  be  improved 
by  not  using  ASCII;  however,  a  translator  must  be  provided 
which  would  convert  thd  internal  code  used  to  ASCII  for 
transmission  over  the  communicarions  lines.  This  decision 
has  resulted  in  performance  degradation  because  code 
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translation  is  wasteful  of  the  resources  of  the  CPU.  [Ref. 

3] 


NA7C0MPAES  is  especially  hindered  by  this  process  of 
code  translation.  Not  only  must  it  contend  with  the  ASCII 
code  used  in  the  Autodin  system,  but  it  also  must  handle 
code  conversion  of  the  five  level  baudot  of  the  high 
frequency  links.  In  that  these  requirements  for  code 
conversion  are  relatively  locked  in  due  to  the  prevailing 
equipment  inventories  and  other  governmental  requirements, 
the  problem  is  to  accomplish  code  conversion  in  the  least 
wasteful  manner.  As  currently  configured,  the  Receive 
Control  Subsystem  manages  code  conversion  for  incoming 
messages  and  the  Transmission  Control  Subsystem  performs 
this  function  on  outgoing  messages.  Both  these  subsystems 
are  core-resident,  thereby  utilizing  the  limited  and 
expensive  core  memory  for  a  standardized  function  performed 
twice  for  every  message. 

As  previously  stated,  additional  programs  are 
contemplated  for  NAVCOMPAHS  which  would  increase  demands  on 
the  limited  amount  of  core  available.  The  DNI7AC  90/60 
processor  currently  has  the  option  to  use  either  EBCDIC  or 
ASCII,  [Bef.  5]  Because  of  the  established  use  of  ASCII  in 
the  Autodin  network,  it  is  strongly  advocated  that  the  90/60 
be  configured  so  that  ASCII  is  the  internal  processing  code. 
Furthermore,  the  rapid  development  of  mini-computers  and  the 
corresponding  decrease  in  their  cost  present  an  alternative 
possibility  which  $hould  be  seriously  explored. 
Concentrators  which  are  mini-computers  have  been  created 
which  could  handle  the  code  translation  function  on  a  more 
economical  basis,  thereby  freeing  the  CPU  for  more  essential 
and  less  routinized  work.  [Ref-  6]  Applicable  cost  analysis 
is  beyond  the  scope  of  this  paper,  but  it  is  recommended 
that  action  be  taken  to  investigate  the  potential  of  using  a 
mini-computer  with  a  code  conversion  capabilbity  in 
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conjunction  with  the  QNIVAC  series  70/45  and  90/60 
processors. 


C.  SOFTWARE 


The  operating  system  for  the  NAVCOHPAES  was  supplied 
by  the  manufacturer,  whereas  the  programs  dealing  with  the 
unique  communications  functions  were  written  by  NAVCOSSACT. 
The  Navy  experiences  a  distinct  advantage  by  having  software 
programs  individually  tailored  to  its  functions  and 
applicable  hardware.  Software  designed  for  specific 
activities  results  in  much  faster  response  time,  although 
the  investment  in  software  programs  is  much  higher  than  if 
standardized  off-the-shelf  software  is  used.  The 
maintenance  of  uniform  software  at  all  NAVCOMPARS  sites  not 
only  increases  interconnectivity,  but  it  also  is  the  most 
cost  effective  method  of  developing  the  extensive  programs 
needed  fcr  a  major  system  like  NAVCOMPARS.  The  software 
currently  operating  on  the  Series  70/45  is  compatible  with 
the  requirements  for  the  Series  90/60  processor;  therefore, 
staying  with  a  UNIVAC  follow-on  computer  will  minimize 
software  transition  costs. 

The  programming  for  this  system  was  done  in  two 
different  computer  languages.  Assembly  language  code  is 
employed  for  those  programs  which  are  used  for  message 
processing  within  the  core.  The  advantage  of  assembly 
language  is  that  it  allows  for  faster  response  time  and 
provides  for  conservation  of  core;  its  main  disadvantage  is 
that  it  is  difficult  to  code.  Most  of  the  NAVCOMPARS 
support  programs  are  done  in  the  Common  Oriented  Business 
Language  (COBOL)  because  these  programs  are  the  ones  with 
which  the  on-site  operators  are  directly  involved.  COBOL 
was  designed  to  be  easy  to  use  and  it  is  well  adapted  to  an 
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external  environment  like  a  NAVCOMHSTA  where  the  majority  of 
users  are  not  computer  experts.  COBOL  is  not  an  ideal 
communications  language  in  that  it  is  a  verbose  language 
which  should  not  be  used  where  speed  and  compactness  of  code 
are  salient  features.  [Eef.  7]  NAVCOMPAES  has  a  mix  of  80% 
assembly  language  and  20%  COBOL  programming.  This  mix 
roughly  reflects  the  division  between  operating  and  support 
programs. 


B.  HOMAN  FACTOES 


In  accordance  with  the  proposition  that  a  communications 
manager  must  treat  with  the  whole  environment  in  order  to 
gain  maximum  performance  from  an  automated  system,  attention 
will  now  ke  focused  on  the  human  element.  This  is  extremely 
important  in  an  automated  system  which  depends  upon  a  myriad 
of  sources  fcr  input.  A  well  constructed  system  design  is 
essential  tc  create  a  viable  package,  but  the  human  factor 
can  be  a  critical  feature.  An  automated  network  places 
additional  requirements  on  operators  as  to  degrees  of 
precision  needed  for  efficient  thruput.  Consequently,  these 
requirements  must  be  identified  and  publicized. 

Humans  are  flexible  and  adaptable,  and  they  can  supply 
corrections  to  plain  text  mistakes  easily  and  quickly;  by 
contrast,  computers  have  rigid  specifications  and  are  very 
unforgiving  of  even  minor  errors.  NAVCOMPABS  was  designed 
to  compensate  as  much  as  possible  for  human  mistakes,  as 
well  as  for  transmission  errors  and  garbles.  As  delineated 
in  Chapter  Four,  the  programs  have  been  written  so  that  the 
computer  processing  immediately  refers  any  error  or 
unaccountable  situation  to  the  VDT  operator  for  manual 
resolution.  This  prevents  messages  from  being  sent  back  to 
the  originator,  but  it  also  slows  down  processing.  The 
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queue  for  the  VDT  operators  is  one  point  of  congestion  which 
can  be  readily  identified.  Errors  which  require  manual 
intervention  can  be  the  result  of  improper  format  used  by 
the  originator,  equipment  malfunction  (particularily  the 
OCEs)  or  poor  quality  high  frequency  transmission  path. 
[Bef.  25] 

One  of  the  input  principles  delineated  in  Reference  19 
is  that  the  volume  pf  data  to  be  produced  by  humans  should 
be  reduced.  In  contradiction  to  this  idea,  NAVCOtlPARS  is  a 
system  in  which  all  imput  is  produced  by  human  operators  of 
varied  training  and  talent.  To  compound  this  situation  is 
the  problem  that  absolute  determination  can  not  be  made  as 
to  the  cause  of  the  errors.  70%  of  all  errors  occur  in 
those  format  lines  (6,  7  and  8)  which  use  the  standardized 
Plain  Language  Address  (PLA)  for  command  short  titles. 
[Bef.  25]  Some  portion  of  the  above  error  total  can  be 
blamed  upon  commands  not  following  the  prescribed  short 
titles  delineated  in  the  Plain  Language  Address  Directory 
(PLAD)  contained  in  NTP  3,  Some  degree  of  flexibility  has 
been  built  into  the  system  through  the  inclusion  of  the 
Alternate  Spelling  File,  which  incorporates  common  short 
title  mistakes  and  connects  these  with  the  correct  routing 
indicator.  Improvements  in  compliance  with  the  PLAD  and 
general  format  conformity  can  only  be  achieved  through  the 
efforts  of  each  individual  command.  Not  only  communications 
personnel,  but  also  message  drafters  and  releasors  must  be 
made  aware  of  the  consequences  of  careless  performance. 
Performance  from  an  individual  point  of  view  strongly 
depends  upon  the  individual's  perception  of  the  importance 
of  the  work  being  accomplished  and  of  his  particular  role 
within  the  whole.  [Bef.  19]  The  average  radioman  onboard  a 
ship  or  small  command  is  unable  to  visualize  how  his  daily 
work  fits  into  the  rather  remote  goal  of  "improving  Naval 
communications  through  automation."  Communications  officers 
have  a  responsibility  for  ensuring  that  their  personnel 
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toward 


understand  their  contribution  toward  inproving  their 
cominand's  communications  record.  The  division  level  is  the 
logical  place  to  start  because  this  is  where  the  work  is 
actually  performed.  The  average  radioman  must  perceive  that 
he  is  a  vital  link  in  the  Navy's  communications  network  and 
that  his  adherence  to  prescribed  procedures  is  beneficial  to 
himself  and  his  ship.  The  NA7C0HMSTa  has  the  function  of 
supplying  all  available  performance  feedback  and  orientation 
on  automated  procedures  and  requirements.  NAVCCMMSIA 
Honolulu  has  personnel  who  are  available  to  indoctrinate  its 
subscribers  in  the  methods  and  procedures  prescribed  for  the 
input  into  the  NAVC0MP4RS.  This  approach  should  be 

instituted  at  all  NAVCOHPARS  sites.  The  area  of 

performance  motivation  affects  every  facet  of  the  Navy 
today,  but  it  is  a  subject  which  is  easier  to  discuss  than 
to  isolate  solutions.  However,  the  human  element  should  not 
be  neglected;  if  personnel  can  be  motivated  ^o  fulfil  their 
role,  communications  automation  can  benefit  from 
improvements  which  depend  not  at 
expenditures  or  more  exotic  equipment. 


all  on  increased 
[Refs,  8  and  14] 


E.  SUMMATION 


The  initial  NAVCOMPARS  site  at  NAVCOMMSTA  Norfolk 
became  operational  in  June  1S73;  since  then  additional 
systems  have  become  operational  at  NAVCOMMSTAs  Honolulu, 
Guam  and  Naples,  Italy.  The  fifth  and  final  NAVCOMPARS  is 
slated  for  installation  at  NAVCOMMSTA  San  Francisco  in  1977. 
The  NAVCOMPARS  has  evolved  into  a  successful  system  which 
has  accomplished  its  stated  objectives  of  providing  faster 
processing  times  and  of  shifting  the  majority  of  time 
consuming  message  handling  tasks  from  fleet  units  to  shore 
based  communications  stations.  NAVCOMPARS  is  not  a 
perfect  system;  software  bugs  are  still  being  uncovered  and 
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hardware  modif icatioas  have  already  "taken  place.  However, 
the  system  has  recorded  a  hardware/software  reliability  of 
98%,  and  it  has  achieved  an  error  rate  of  less  than  1%  of 
all  messages  processed.  [Ref.  21]  It  is  a  dynamic  system 
which  is  continuing  to  grow  and  to  assume  new  capabilities. 
Projected  enhancements  include  the  consolidation  of  special 
intelligence  and  general  service  traffic,  the  installation 
of  the  BJXT  terminals  and  full  implementation  of  the  IXS 
program. 

This  thesis  has  constructed  a  flowchart  model  of  the 
message  handling  procedures  which  could  be  used  as  an 
instructional  tool  to  introduce  communications  personnel  to 
the  characteristics,  capabilities  and  limitations  of 
communications  automation.  Specific  recommendations  have 
been  made  throughout  the  body  of  the  text  and  will  not  be 
repeated  here.  Perhaps  the  most  important  aspect  of  this 
thesis  is  the  delineation  of  the  limitations  of  automation. 
Continued  benefits  for  naval  telecommunications  through 
system  automation  will  ensue  only  if  system  reguirements  are 
understood  and  supported  by  all  users.  The  following 
NAVTELCOM  statement  issued  in  1973  is  still  valid  today 
[ Ref.  4 ]: 

"Success  depends  upon  strict  adherence  to 
orescribed  procedures  and  formats,  most  of  which 
Are  currently  effective.  Failure  to  comply  will 
negate  the  advantage  of  automation." 
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APPENDIX  A 


EXPLANATION  OF  FLOWCHART  SYMBOLS 
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COMMUNICATIONS  LINK 
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